웹 배포

Published at 2025-01-15

#

개요

웹 배포에 대한 전체적인 그림을 톺아보면서 개념을 확실히 하자.

웹 어플리케이션의 구성

웹 어플리케이션은 크게 3가지로 요소로 구성된다.

  1. 클라이언트
  2. 프론트엔드 서버 (웹 서버)
  3. 백엔드 서버 (API 서버)

![[Pasted image 20250113214206.png]]

클라이언트

사용자가 보는 화면에 대한 소스코드를 칭한다.

  • HTML 코드
  • CSS 코드
  • 그리고 그것들을 인터렉션하게 만들어주는 JS 코드

이렇게 구성되어 있다.

프론트엔드 서버

일단 내가 생각하는 웹 서버

유저가 IP 내지는 도메인을 입력하면, 웹 페이지를 반환해줌

근데 그냥 HTML CSS JS를 뱉는 게 아니라, 렌더링 전략에 따라 좀 다르다는 거임.. 이게 내가 헷갈리는 부분인 거 같은데…

CSR

CSR은 Client Side Rendering.

뼈대가 되는 HTML CSS 그리고 동적으로 DOM을 만들고 라우팅 처리를 하고.. 모든 것을 하는 JS 파일. (너무 사이즈가 크니까 chunks로 조각나 있다.)

![[Pasted image 20250113225634.png]]

이건 React로 만든 나인하이어 앱인데, 맨 위에 HTML 파일 하나가 있다. 그 아래로 CSS 파일 여럿 그리고 매우 많은 JS 파일들.

JS 파일은 HTML의 특정 div를 붙잡고 DOM을 추가하겠지..

SSR

SSR은 Server Side Rendering.

서버에서 렌더링 한다는 거다.

아.. ChatGPT의 힘을 쓰자. 예시로 Next.js의 getServerSideProps 의 동작 과정을 살펴봤다.

SSR(getServerSideProps)의 동작 과정을 다시 정리하면 다음과 같습니다:

Chat GPT의 응답

SSR 동작 과정 (getServerSideProps)

  1. 검색 엔진 크롤러 또는 사용자 요청:

    • 검색 엔진 크롤러(또는 일반 브라우저)가 동적 라우트에 해당하는 URL에 접근합니다.
    • 예: https://example.com/blog/my-post.

  2. 웹 서버에서 요청 처리:

    • Next.js의 웹 서버가 요청을 수신합니다.
    • 동적 라우트를 감지하고, 해당하는 페이지 파일([slug].js)을 찾아 실행합니다.

  3. getServerSideProps 실행:

    • 웹 서버는 getServerSideProps 함수를 호출하여 데이터를 가져옵니다.
    • 이 과정에서 필요한 데이터를 API 호출, 데이터베이스 쿼리, 외부 서비스 요청 등을 통해 동적으로 생성합니다.

  4. HTML 렌더링:

    • getServerSideProps가 반환한 데이터를 기반으로 React 컴포넌트가 서버에서 렌더링됩니다.
    • 이때 완성된 HTML이 생성됩니다.

  5. 완성된 HTML 반환:

    • 생성된 HTML이 웹 서버에서 클라이언트(검색 엔진 크롤러 또는 사용자 브라우저)로 반환됩니다.
    • 브라우저나 크롤러는 이미 완성된 HTML을 받으므로, JavaScript 실행 없이도 콘텐츠를 바로 볼 수 있습니다.
예시

URL 요청: https://example.com/blog/my-post

  1. 크롤러 요청:
    GET /blog/my-post

  2. 서버 동작:

    • Next.js가 /blog/[slug].js를 찾음.
    • getServerSideProps가 호출되어 데이터(slug: my-post)를 가져옴.

  3. HTML 생성:

    • React 컴포넌트가 서버에서 렌더링되어 다음과 같은 HTML이 생성: 
      <html>
	<head>
		<title>My Post</title>
	</head>
	<body>
		<article>
			<h1>My Post</h1>
			<p>This is the content of the blog post.</p>
		</article>
	</body>
</html>

  4. HTML 반환:

    • 생성된 HTML이 클라이언트(크롤러)로 반환됨.
장점
  • SEO 최적화: 크롤러는 JavaScript 실행 없이 완성된 HTML을 읽을 수 있습니다.
  • 실시간 데이터 반영: 요청 시마다 최신 데이터로 페이지가 생성됩니다.
  • 유저 맞춤 콘텐츠: 지역, 언어, 로그인 상태에 따라 맞춤 콘텐츠 제공 가능.
결론

말씀하신 순서대로 동작하며, getServerSideProps를 통해 서버에서 HTML이 완성된 후 반환되기 때문에 검색 엔진 크롤러가 동적 라우트를 제대로 색인(indexing)할 수 있습니다. 😊

나의 정리

그러니까, 사용자가 라우트에 접근하면, 웹 서버에서 데이터를 요청하고 웹 서버에서 데이터를 가지고 HTML을 만들어서 사용자에게 전달한다는 거다.

사용자는 완전히 인터렉션 가능한 페이지를 한 번에 받을 수 있지만, 렌더링이 오래 걸린다면 그만큼 빈 페이지를 보고 있는 시간이 길어질 것이다.

정리

웹 페이지를? 웹 어플리케이션을 반환한다! 라는 건 맞음

근데 어떻게 유저에게 응답하느냐? 는 그 전략에 따라 달라짐.

빈 HTML과 함께 빈 HTML을 채워주는 엄청 큰 JS파일을 보낼 수도 있고, 이미 모든 게 완성된 HTML만 보내줄 수도 있고, 뼈대 정도만 있는 HTML과 함께 살을 붙여주는 JS파일을 보낼 수도 있다.

백엔드 서버

뭐.. 백엔드 서버다. API를 요청 받으면 적절한 처리를 하고, DB와 연결되어 관리하고.. 그런 것들?